Increasingly, documents and other collections of stored information are made up of multiple content elements, such as text, tables, images, formatting information, mathematical equations and graphs. Often content is created using one application program and then included in documents created by other applications. Subsequently, content elements may be copied out of a document and used in yet another document, and so on.
In the past, different applications typically had no way to exchange multiple content elements, unless they had a "private contract" about the format to be used. Furthermore, one application typically had no way to find the content elements in another application's document, so typically it was not able to obtain content elements from the other application's documents even if it knew the format. Moreover, every application developer who wanted to store multiple content elements in a document typically had to develop a proprietary object storage mechanism.
The use of multiple content elements in a document implicates at least two difficult issues: where each element is located and what the format of the data is. Regarding the first of these issues, it would be desirable if the data in a particular element could be stored in memory, in a local persistent storage device, across the network, or even created dynamically, all in a manner which is transparent to the application program which is operating on an element. In this way the limited resources available to application program developers can be directed toward enhancement of functionality rather than dealing with multiple types of storage devices.
Similarly, with regard to the second issue, it would be desirable if each different content element could have stored in association with it all of the routines which are needed to manipulate it, again, transparently to the application program. This, too, would free up developers' resources for more useful purposes.
In a general way, an individual developer might obtain some of the transparency described above by programming the application using an object-oriented programming language such as C++. Object-oriented programming is described in many references, including, for example, G. Booch, "Object-Oriented Design With Applications" (Benjamin/Cummings Publishing Company: 1991), incorporated herein by reference. Such languages often support the grouping together of both an item of data and a set of "methods" to manipulate the data, in a single "object". These languages also often include, through a mechanism known as "classing" and "sub-classing" of objects, a way to define inheritance relationships. In an inheritance relationship, if a routine to perform a certain type of manipulation is not defined for a particular object in a particular class, then the corresponding routine in the parent class is used instead.
While these languages can be used to address the problems described above for handling multiple content elements, it is not clear how that can be done. Certainly the languages themselves do not provide guidance on how they can be used for such purposes. For example, the inheritance mechanism in C++ is a compile-time mechanism.
The languages also permit a method for a given object (whether the method is defined specifically for the object's own class or is inherited from a superclass) to invoke other methods for operating on the given object. The method can also invoke whatever corresponding method is defined for the object's superclass, for operating on the given object, and need not know exactly which routine that might be. While these features permit some degree of hiding or encapsulation, they do not provide enough flexibility for easy development of application programs which manipulate multiple content elements since to some degree, the application program still needs to know the type of the object it is operating on.